From: "David B. Bryant 444-4399" <[email-masked]>
Date: Fri, 11 Jun 93 10:46:34 EDT

Subject:Answers to questions.

David - see my answers listed under your questions below.
----- AIWDLUR DIGEST appended at 22:09:27 on 93/06/07 GMT (by NSAECHO at RALVM6)
Subject: questions on architecture document
From: [email-masked]  (David Matusow)
Date: Mon, 7 Jun 93 18:08:15 -0400
Reply-To: [email-masked]
Message-Id: <[email-masked]>

    Questions on APPN Dependent LU Requester Architecture
                 Document dated June 3, 1993

1. In bullets under 5.7.3.1

   halfway down page. - "determined" vs. "determined"  what
   is this supposed to be?

The terminology "determined" means that the DLUR has discovered a DLUS
without pre-defining one (e.g., a DLUS has contacted the DLUR).  "determined
vs. determined" means that the DLR has discovered multiple DLUS nodes
and the DLUR implementation is allowed to chose any DLUS it likes.

2. In figure 5-14

   What is supposed to drive the detection of loss of
   CPSVRMGR from VTAM1?

The APPN CP.LU has option set 401 (reliable one way brackets).  This
option set provides for the ability to specify a "session termination
TP" in the DEFINE_MODE command.  Both CPSVCMG and CPSVRMGR specify
such a TP
which the CP.LU Resource Manager (RM) will invoke when it receives
session termination notification from the Session Manager (SM) component
of the CP.LU.  Therefore, when a CP-CP or CPSVRMGR session fails,
RM will kick of the specified session termination TP and pass it the
session failure sense data as PIP data.  The session termination TP
then notifies the Session Services component of the APPN control
point, by sending it a signal carrying the session failure sense data.
This is very well described for CP-CP sessions in SC30-3422-3 chapter
5.  It is basically the same for CPSVRMGR sessions, we just need
to specify the appropriate TP name for the CPSVRMGR logmode.

   It would seem more appropriate to include a CV in the BIND
   to indicate that this is a takeover of the previous SSCP.
   this way, there are less flows necessary and management is
   kept more current.

The amount of component level changes with kind of approach is considerably
more.  In addition, managing race conditions would require additional
logic as well.  It is more appropriate to leverage the existing function
in the architecture to accomplish the same result.  I suggest discusing the
details of this proposal with either Ed Tremblay or myself at the AIW.
If you do not intent to attend, give us a call and we can chat.

3. paragraph 4 page 6-18

   What is RSCV?  I assume that this is a control vector, but
   I'm not familiar with this one.

RSCV = Route Selection Control Vector.  It specifies the route for
a specific message (either Locate or BIND).  It's explained in SC30-3422-3.

OVERALL IMPRESSION

I think that this is a reasonable design.  It's unfortunate
that the dependent LU support can't be driven from the DLUR,
but this is not an easy port of code (nor small!!).

===> This is exactly why DLUR was created.

The use of the DLUR as the end point of the session if DLUR
is an EN is unfortunate (see page 8-1), as this may not be
the most direct route to the physical PU/LU.  It would seem
that the tail vectors off of the TGV would give sufficient to
get the "full" routing.  (It might be that this IS true and
that I'm just misinterpretting.)

===> I don't understand what point you're making here, but sessions
to dependent LUs on an EN DLUR will flow directly from CP(PLU) to the DLUR.
If the PU/LU is downstream from the DLUR, the BIND MUST flow through the
DLUR even though the PU may have additional links to other parts of the
network.  This is becuase the original Subarea dependent LU architecture
associates a dependent LU with a single link.  Messages are routed to the
dependent LU based upon the recieved DAF address in the FID2 header.
This DAF address is associated with a given link, therefore, addressing
of packets to a specific dependent SLU is done by assigning the
appropriate DAF and sending it over a specific link.  So a dependent
LU is actually associated with one and only one link off the Boundary
Function.  Hope this helps.